REMARKS 

This Amendment is in response to the Office action dated 
November 23, 2007. Claims 1-5 have been amended in order to 
more clearly distinguish the invention from the prior art, and 
claims 11-20 have been cancelled. New claims 21 and 22 have 
been added. No new matter has been added by way of this 
Amendment . 

The Examiner has rejected claims 1 and 2 under 35 USC 102(e) as 
being anticipated by Deaton et al . (USP 6,334,108). The 
Examiner has also rejected claims 3, 4 and 11-14 under 35 USC 
103(a) as being unpatentable over Deaton in view of Klayh (US 
2003/0050831) . The Examiner has also rejected claims 5-7 and 15- 
17 under 35 USC 103(a) as being unpatentable over Deaton on view 
of Klayh as applied to claims 3 and 13, in further view of 
Harris et al . (USP 6,014,635). The Examiner has also rejected 
claims 8, 9, 18 and 19 under 35 USC 103(a) as being unpatentable 
over Deaton on view of Klayh as applied to claims 3 and 13, in 
further view of Official Notice. The Examiner has also rejected 
claims 10 and 20 under 35 USC 103(a) as being unpatentable over 
Deaton on view of Klayh as applied to claims 3 and 13, in 
further view of Blagg et al . (USP 7,076,465). 

Applicant respectfully disagrees with the interpretation of the 
references as they allegedly apply to the Applicant's claims as 
explained herein. Applicant has amended the claims as explained 
in order to more clearly distinguish from the references cited. 

The present invention is a reward point system that utilizes the 
pre-existing infrastructure of a typical card network such as a 
credit card network. A user will make a purchase at a merchant 
of a product using a token such as a credit card. The merchant 
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contacts the acquiring bank with which it has contracted for 
credit card network services, and as known in the art, will get 
an approval or decline message after the acquiring bank contacts 
the issuing bank of the credit card used by the purchaser. 
Assuming that the purchase transaction is approved, the user is 
awarded reward points from the merchant based on the amount of 
the purchase (e.g. 100 points for a $100 purchase). A central 
server computer resides on or otherwise interacts with the card 
network and tracks the transaction between the merchant, the 
acquiring bank, and the issuing bank. A reward account is 
maintained on the central server on behalf of the merchant and 
the user, and the number of reward points in the user's account 
for that merchant is increased accordingly. The user may redeem 
the reward points earned from the transaction with the merchant 
at a later time, or may redeem the points with another merchant 
on the card network, or may aggregate those reward points with 
those of other merchants into a central exchange account, and 
then redeem the aggregated points for goods or services from any 
approved merchant on the network, depending on the configuration 
of the system. 

Claim 1, as amended, therefore recites a method of operating a 
reward points system in conjunction with a card network, with 
the card network comprising at least one issuing bank for 
issuing a card to a user and at least one acquiring bank for 
collecting payment from the issuing bank on behalf of a merchant 
and paying the merchant. A reward point account database is 
established in a central reward server operating in association 
with the card network. The central reward server enables a 
plurality of independently operating merchants to each have a 
plurality of individual user reward point accounts stored in the 
reward point account database and associated with the 
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independently operating merchant. To utilize the system, a user 
executes a purchase transaction with one of the transacting 
merchants (from the group of independently operating merchants) 
by presenting to the transacting merchant a card for payment of 
the transaction. The transacting merchant then requests an 
acquiring bank to obtain approval of the purchase transaction 
from an issuing bank. The transacting merchant instructs the 
central reward server to add reward points to a user reward 
point account associated with the transacting merchant and the 
user. Thus, this claimed system enables any number of 
independent merchants to establish reward point accounts for 
their customers using the infrastructure of the card network, 
without having to establish their own proprietary reward system 
as in the prior art. The central reward server can track reward 
point accounts for numerous users at numerous merchants as 
independent accounts, thus providing brand distinction and 
loyalty. As a result, each participating merchant is provided 
with a reward system managed by an independent entity using 
selective collaboration, allowing the merchant to maintain brand 
identification and name recognition. 

This is not the system that is described in Deaton. Deaton' s 
system provides targeted marketing to customers utilizing credit 
card account codes, for example, without having to use a 
marketing card (Deaton col. 4 lines 51-55). Deaton also provide 
credit verification on a local basis. In particular, Deaton 
provides a system in which an individual store has a local 
customer database of customer records, each record having credit 
verification data and other transactional data (Deaton col. 5 
lines 14-22) . Deaton uses a local customer database for each 
store for credit functions as well as to perform "targeted 



8 



marketing functions based upon the customer's prior shopping 
history" (Deaton col. 5 lines 38-54). 



Deaton specifically requires local customer databases: 



Moreover, because the transactional data is generated 
and maintained locally, it provides significant 
information about the store's customers over and above 
the information necessary for verification risk 
management. New customers are readily identified, and 
prior shopping history such as frequency and dollar 
volume information may be used to establish customer 
profiles and to target advertising, marketing and 
promotional programs, and for other customer relations 
purposes . 

Deaton, col. 6 lines 26-35 (emphasis added). Deaton 
specifically states that a local customer database is an 

important feature and advantage of the system (Deaton, col. 6 
line 62 through col. 7 line 2). 



Deaton addresses a multiple store business scenario, but not one 
in which multiple independent businesses may implement the 
system: 

In the case of a multiple store business, each store 
has a local transaction processing system, with one of 
the systems being designated a host site and the rest 
being designated remote sites. At selected intervals, 
each remote system transmits to the host selected 
customer information from its local customer database 
(such as customer records for those customers with 
CAUTION and NEGATIVE status including transactional 
data) , which is used to update the host customer 
database to include this global customer information. 
The host, in turn, transmits that global customer 
information to the other remote systems. 

Deaton, col. 6 lines 36-46 (emphasis added). 
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In this embodiment, there are multiple individual local 
databases, with one of them designated a host site and the 
others as remotes. Information is sent from the remotes to the 
host, and then that host information is sent to the other remote 
databases. This complicated multiple-database synchronization 
scenario is not what the Applicant has claimed as explained 
further below. 

Claim 1 as amended herein recites that a reward point account 
database is provided in a central reward server operating in 
association with the card network. The central reward server 
enables a plurality of independently operating merchants to each 
have a plurality of individual user reward point accounts stored 
in said reward point account database and associated with said 
independently operating merchant. Deaton does not provide for a 
central reward server with a multiple-merchant database as 
claimed - rather, Deaton uses multiple individual store-based 
databases that must be periodically synchronized with each 
other. In addition, this multiple-store environment does not 
appear to allow for independent merchants to interoperate with a 
central reward server as claimed - it is simply a single-owner 
business with multiple stores that would be able to synchronize 
their information. Such a synchronization methodology would not 
operate with multiple independent businesses, but the claimed 
central reward server and multiple merchant database will solve 
this problem. That is, the central reward server is able to 
track reward point information in separate accounts for each 
merchant and user, as explained in the Applicant's 
specification : 

For example, the Smith Pizzeria will advertise that a 
$100 purchase will yield 100 "Smith Pizza Points" for 
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a purchaser. The merchant here is able to provide 
this feature without having to establish an expensive 
infrastructure (i.e. sever computers, administrators, 
etc.) as in the prior art. Likewise, it is able to 
award its own branded loyalty points as not seen 
before in the prior art (rather than simply 
distributing airline points or hotel points) . In 
addition, the system may be configured so that the 
credit card network operator that operates the central 
server (e.g. VISA or MASTERCARD) is co-branded with 
the local merchant awarding the loyalty points. Thus, 
the loyalty points may be referred to as "Smith's 
Pizza/ VISA Points", or "BLOCKBUSTER/VISA Points", or 
"GAP/VISA Points", etc. 

The merchant is thus able to leverage its pre-existing 
contractual relationship with the acquiring bank and 
the credit card network, and either the central server 
(in one embodiment) or the acquiring bank (in another 
embodiment) will keep track of the loyalty points 
awarded by the merchant to all of its customers. 
Similarly, hundreds or thousands of similar accounts 
with other merchants will be kept track of in the same 
manner. 

The maintaining of these merchant loyalty points may 
be undertaken by storing user and merchant account 
information in a database associated with the central 
server as shown in Figure 12. Thus, Figure 12 
illustrates a simple database format wherein each 
merchant and user under that merchant has a record 
which indicates how many points are in the account, as 
well as other optional information (such as par value 
of points, restriction on use, etc.) The format of 
the storage of the information is unimportant and may 
take many forms as well know in the art of relational 
and other types of databases. A simple transaction 
log may keep information on each transaction processed 
by the acquiring and issuing banks; this log may be 
easily modified to include loyalty point information 
as well. 

Specification, page 10 line 32 - page 12 line 5 (emphasis 
added) . Thus, the central reward server has numerous reward 
point accounts for different users and different merchants ("the 
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central reward server enabling a plurality of independently 
operating merchants to each have a plurality of individual user 
reward point accounts stored in said reward point account 
database and associated with said independently operating 
merchant"). Deaton' s system uses a single local customer 
database and does not teach or suggest the central reward server 
of this invention as claimed. 

In addition, Deaton does not provide for the maintaining of 
reward point accounts in the central reward server as presently 
claimed. The information stored in the customer accounts of the 
Deaton reference is "prior shopping history" that enables Deaton 
to generate coupons or other incentives at the point of sale or 
for later mailings (col. 7, lines 40-60). This is qualitative 
data used to generate coupons. The Examiner "interprets coupons 
and other incentives to be equivalent to the Applicant's reward 
points". Applicant respectfully disagrees with this statement 
that has no basis, and maintains that the reward point accounts 
as presently claimed are not anticipated by the Deaton 
description of coupon generation based on prior shopping 
history. 

Thus, claim 1 is not anticipated by Deaton and is in condition 
for allowance. Claim 2 depends from claim 1 and recites a 
method of redeeming reward points from a user reward point 
account with a redeeming merchant, which is a merchant that may 
not necessarily be the transacting merchant that initially 
awarded the reward points to the user. Claim 2 is also 
patentable for at least these reasons. 

Claim 3 as amended depends from claim 1 and adds the limitations 
of establishing a reward point exchange account on the central 
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reward server; selecting reward points from each of a plurality 
of user reward point accounts associated with different 
independently operating merchants for exchange into the reward 
point exchange account; and aggregating the selected reward 
points into the reward point exchange account. The Examiner 
asserts that "Deaton discloses his system being used with 
multiple store businesses and an Event Manager Task that 
implements system's activities and transfers customer data among 
the stores". The Examiner also states that Deaton necessarily 
includes establishing a reward point exchange account and 
aggregating the selected reward points because "Examiner knows 
of no other way to utilize reward points without establishing a 
reward point exchange account. Therefore Examiner asserts that 
Deaton inherently teaches establishing a reward point exchange 
account". The Applicant respectfully disagrees with the 
assumptions the Examiner makes. 

First, the Examiner's interpretation of the multiple store 
businesses as having Applicant's plurality of merchant reward 
point accounts is incorrect. As explained above, the Deaton 
reference has a single business with multiple stores, each 
having its own local database with local customer information. 
Deaton explains only that information from a customer account in 
one store may be sent to the host database, and then that host 
information is sent to the other remote databases. Applicant 
has clarified in its claim 3 that the reward point accounts are 
associated with different independently operating merchants. As 
such, the reward points may then be exchanged (aggregated) into 
the reward point exchange account. 

In a further embodiment, the user/purchaser may 
aggregate reward points from more than one loyalty 
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point account to increase his purchasing power. That 
is, he may have dozens or even hundreds of similar 
reward accounts with the various merchants with which 
he does business; such as hardware stores, movie 
theaters, car washes, video rental stores, gas 
stations, hotels, airlines, etc. Since any type of 
merchant that accepts a credit card such as VISA or 
MASTERCARD is empowered with a custom-tailored loyalty 
program (or a global universal network based rewards 
program) under this invention, there is virtually no 
limit to the number and type of loyalty accounts that 
a user may have. 

Loyalty points aggregation is undertaken by an 
exchange server, which may be on the same computer as 
the central server that stores the loyalty point 
records for each merchant and user. The exchange 
server allows a user to view his loyalty points 
portfolio easily (such as on a web page) , it allows 
the user to manage the exchange of loyalty points from 
any of his individual merchant accounts into his 
exchange account, and it allows the user to execute 
purchase transactions with his aggregated loyalty 
points. For example, user John Doe may establish an 
exchange account with VISA directly, and VISA will use 
his account number (with appropriate security 
procedures) to determine all of the loyalty database 
records on the central server. John Doe will not need 
to enter dozens or even hundreds of account numbers, 
since his loyalty accounts will be tied directly to 
his credit card number. Once the central exchange 
server obtains his loyalty points information from the 
various databases and separate accounts, it will 
generate a web page to display the account totals to 
the user. The user can then instruct the central 
exchange server to exchange points into his exchange 
account from selected accounts as desired. 
Consideration will be provided from the merchant to 
the central server that correlates to the number of 
points exchanged. So, for example, if the user 
requests that 5,000 points be transferred from his 
Smith Pizzeria loyalty account to his VISA exchange 
account, then the Smith Pizzeria account will be 
reduced by 5,000 points and the acquiring bank will 
transfer $50 (minus a merchant exchange fee) to the 
VISA server. The Smith Pizzeria acquiring bank will 
invoice the merchant by the reduced amount, which may 
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for example be $30. The purchaser will no longer be 
able to obtain a direct loyalty discount for those 
points with the merchant since he has exchanged them 
into his central account. (He may still be able to 
redeem his exchange points with that merchant as part 
of a network-based transaction, described below) . 

Specification, page 16 line 21 through page 18 line 4 (emphasis 
added) . This is clearly different from having multiple stores 
in the same business with separate databases that are 
synchronized with each other, since there is no central reward 
point exchange account in Beaton - just multiple individual 
databases that must synchronize with each other. Deaton' s 
system will result in the various local database each having the 
same information (after synchronization) - which is not the same 
as exchanging reward points from various merchant accounts into 
a single exchange account. In Applicant's claimed method, the 
exchange account has different reward point totals than the 
separate reward accounts since the points are traded/exchanged 
into that exchange account, while in Deaton, the local databases 
will end up with the same information. The Examiner has no 
basis for surmising that the Deaton system must have an inherent 
exchange account but this is not the case since Deaton intends 
on having multiple local databases to each have the same 
information, while the reward exchange account as claimed will 
have different point totals than the separate merchant reward 
accounts. This underscores the difference between reward points 
in reward points accounts as presently claimed and simple 
qualitative marketing information that is shared amongst various 
local databases as in Deaton. There is no reason for the Deaton 
system to have a reward point exchange account and the 
Examiner's statement that there must be one in there somewhere 
is incorrect. Thus, claim 3 is in condition for allowance. 
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Claims 4-10 depend from claim 3 and are also allowable for at 
least these reasons. 

New claims 22 recite limitations on the redemption process of 
claim 2 in which reward points are used as complete 
consideration for the purchase (claim 21) and partial 
consideration for the transaction (claim 22) . 

Applicant thus submits that the entire application is now in 
condition for allowance, early notice of which would be 
appreciated. Should the Examiner not agree with the Applicants' 
position, a personal or telephonic interview is respectfully 
requested to discuss any remaining issues and expedite the 
eventual allowance of this application. 



February 14, 2008 
20 Gateway Lane 
Manorville, NY 11949 
(631) 259-9099 



Respectfully submitted, 

/arbarkume/ 

Anthony R. Barkume 
Attorney for Applicant 
Reg. No. 33,831 
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